System and method for a cics application using a same program on a local system and a remote system

ABSTRACT

A system and method implemented in a Customer Information Control System (CICS) Application configured to process information residing on remote systems and display such information on a local system, using a same program residing on both the remote system(s) and the local system. The method includes, for example, sending programming functions of a local system with a request for information to a remote system. The method further includes processing the programming functions of the local system with the request for information on the remote system to obtain updated information from the remote system. The updated information is sent to the local system for display.

FIELD OF THE INVENTION

The present invention relates generally to computer systems, and moreparticularly to a system and method for processing a remote request.

BACKGROUND OF THE INVENTION

CICS is a transaction processing system designed for both online andbatch activity. On large IBM zSeries and System z9 servers, for example,CICS easily supports thousands of transactions per second, making it amainstay of enterprise computing. For this reason, CICS is used in bankteller applications, airline reservation systems, ATM systems, etc.

However, an application program designed to execute in the CICSTransaction Server environment can only access storage within its localCICS region. For example, with distributed processing, many remotelyconnected CICS regions can distribute databases and workload for loadbalancing to make the most efficient use of processing capacity. Thiscauses customer information to be distributed, which requires complexcoding techniques. This also can make application support and problemdetermination difficult and time consuming, which can have a negativeaffect on customer satisfaction and application availability.

CICS applications can be written in numerous programming languages,including COBOL, PL/I, C, C++, IBM Basic Assembly Language, REXX, andJava. But, programming techniques to provide access to storage on aremote CICS region can be complicated and require multiple programs. TheCICS Transaction Server for z/OS and V2R3 CICS Application ProgrammingReference (SC34-6232) describes the available commands to accessresources controlled by CICS, and the CICS Transaction Server for z/OSCICS Intercommunication Guide (SC34-6243) describes methods ofCICS-to-CICS communication.

By way of example, the programming options available to the CICSapplications include:

-   -   1. Intersystem Communication (ISC): ISC uses Advanced Program to        Program Communication (APPC) which requires a client and server        program relationship on both ends of the connection. APPC is a        detailed protocol with distinct functions for each end of the        conversation and requires careful coding of data syncpointing        and error condition processing.    -   2. CICS Function Shipping: CICS Function Shipping provides        access to resources and Virtual Storage Access Method (VSAM)        files on a remote CICS region as if they were locally defined.        The CICS Function Shipping does not provide a method to access        storage (memory) or DB2 databases within the remote CICS region.    -   3. Asynchronous Processing: Asynchronous Processing allows a        local CICS program to initiate a transaction on a remote CICS        region and pass data to it, but no reply is possible.    -   4. Transaction Routing: Transaction Routing allows a local        transaction to be shipped to a remote CICS region for        processing, but there is no return to the originating CICS        region.    -   5. TCP/IP sockets: TCP/IP sockets can be used in a client/server        program relationship, with a complex send/receive protocol for        each end of the communication channel and detailed error        condition handling.    -   6. MQSeries: MQSeries can be used to send a request to a remote        system via a message queue and receive a response message.        MQSeries is designed to be asynchronous, so complex programming        methods must be utilized to send a synchronous request and wait        for a response.    -   7. Distributed Program Link (DPL): DPL allows a local CICS        program to initiate a program on a remote CICS region. Data can        be passed to the remote program and response data can be        returned. The remote program has full access to all storage and        databases on the remote CICS region and can pass information        back to the originating program.        All of the above options require a detailed understanding of the        selected programming interface, and in most cases require a        separate type of programming on each end of the communication        connection.

The DPL option provides the simplest method for a program to communicatewith another program on a remote system. In DPL, the remote program hasaccess to every resource, database, and storage area on that CICSregion, as well as connecting to another CICS region through the sameinterface. However, in order to pass information between the local andremote programs, a common data area (also referred to as “commarea”) isused. This is typically a data structure with defined fields whichdifferent programs at both ends utilize.

In the DPL type implementation, the required components include a sourceprogram, a target program, and the data defining area (copybook ormacro) used to pass information between the source program and thetarget program. The target program, for example, is unique because itresponds to the source program, in order to obtain data from the remotesystem. However, in implementation, it is not possible to directlyaccess the data on the remote system; it is only possible to access thefiles on the remote system. That is, it is not possible to access thestorage area on the remote system, using the local source program.Access to the storage area on the remote system is only possible usingthe target program on the remote system. Additionally, the data definingarea has to be created such that it includes all fields associated withthe remote system and it must be synchronized between the source programand the target program. This being the case, when a field in the datadefining area is changed, the target program must have a correspondingchange and, if not, the data will be corrupted. Accordingly, in use, theimplementation of the source program, target program, and data-definingarea requires additional programming and careful attention tosynchronization, amongst other things.

Accordingly, there exists a need in the art to overcome the deficienciesand limitations described hereinabove.

SUMMARY OF THE INVENTION

In a first aspect of the invention, a method comprises sendingprogramming functions of a local system with a request for informationto a remote system. The method further includes processing theprogramming functions of the local system with the request forinformation on the remote system to obtain updated information from theremote system. The updated information is sent to the local system fordisplay.

In another aspect of the invention, a system for obtaining informationfrom a remote system comprises a computer infrastructure having one typeof program for a local system and the remote system. The program isoperable to send programming functions of the local system with arequest for information to the remote system, process the programmingfunctions of the local system and the request for information on theremote system and send the updated information to the local system fordisplay, via a defined common area storage.

In another aspect of the invention, a computer program productcomprising a computer usable medium having readable program codeembodied in the medium is provided. The computer program productincludes at least one component to perform the steps of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows an illustrative environment for implementing the steps inaccordance with the invention;

FIG. 2 shows an architecture in accordance with an aspect of theinvention;

FIG. 3 is a flow chart of steps for implementing aspects of theinvention; and

FIG. 4 is an illustrative graphical representation (screen shot)implementing aspects of the invention.

DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION

The invention relates to a system and method implemented in a CustomerInformation Control System (CICS) Application configured to processinformation residing on remote systems and display such information on alocal system, using a same program residing on and/or associated withboth the remote system(s) and the local system. The invention can beimplemented over any distributed network, for example, and any existingprogram can be modified to take advantage of the benefits andfunctionality of the system and method of the invention. In onepreferred embodiment, the system and method is implemented on IBMmainframe systems under Z/OS, z/VSE, i5/OS or OS/2 operating systems,amongst other implementations.

The system and method of the invention requires only one program to bedeveloped which executes on both ends of the communication channelwithout any communications interface programming; compared to aclient/server model using separate programs and complicatedcommunication protocols. Additionally, in the system and method of theinvention all of the defined dynamic storage is available to the programon both ends of the communications link, making the process oftransferring programming functions from one system to another seemnearly transparent. In such implementations, the system and method ofthe invention takes virtually the entire working storage of the program(on the local system) and passes it to and returns it from the programon the remote system. Also, the program implemented in the system andmethod of the invention is configured in such a manner as to allowaccess to the storage area on the remote system using the program on thelocal system.

In implementation, the system and method of the invention utilizes aDistributed Program Link in such a manner as to eliminate the need for atarget program and data defining area. In this manner, the system andmethod of the invention greatly simplifies the required programming intoa single program, which handles both client and server functions andeliminates communications protocol requirements. That is, for example,in implementation, the system and method of the invention defines amethod for a program executing on a local (originating) CICS region toaccess information on a remote (target) CICS region.

System Environment

FIG. 1 shows an illustrative environment for managing the processes inaccordance with the invention. The illustrative environment may be aserver or a user workstation, for example, and may represent both alocal system 10 a and a remote system 10 b implementing a CICS. In onepreferred embodiment, the illustrative environment is implemented on IBMmainframe systems under z/OS, z/VSE, i5/OS or OS/2 operating systems(O/S), amongst other implementations.

The environment includes a computer infrastructure 12 having a computingdevice 14 (e.g., including a source/target program). More specifically,the computing device 14 includes a program 16 a, 16 b, which isidentical on both the local system 10 a and the remote system 10 b. Inthis manner, it is possible to eliminate the use of different programson the local system 10 a and the remote system 10 b. Although not shown,the remote system 10 b may additionally include the remaining or similarcomponents that reside on and/or are associated with the local system 10a, e.g., ROM, storage, external devices, etc, as described herein. Thelocal system 10 a can be linked to the remote system 10 b using, forexample, any type of networks (e.g., the Internet, a wide area network,a local area network, a virtual private network, etc.); and/or any knowntransmission techniques/protocols (e.g., TCP/IP).

In embodiments, the program 16 a, 16 b performs several functionsincluding, for example,

-   -   (i) organizing all of the program's working or dynamic storage        into a defined data structure;    -   (ii) recognizing, validating and processing the input for a        remote system request; and    -   (iii) performing a simple Distributed Program Link (DPL) call to        the same program residing on the remote system (as is on the        local system), and passing the working storage data structure in        a CICS Link Commarea (common area between the remote and local        systems).        Additionally, in further embodiments, the program 16 a, 16 b        includes executable code, which may be stored temporarily or        permanently in a memory 22A. As should be understood by those of        skill in the art, the executable code can be configured to        implement the above functions.

In implementation, the program 16 b on the remote system 10 b will useinformation in a commarea storage 17 (herein after referred to as acommon area storage) as its working storage to collect and process therequested information and return it to the calling program on the localsystem 10 a. Also, if 3270 type screens are used, the screen data can beformatted in the working storage on the remote system 10 b. (The 3270type screen is represented as I/O device 28.) As discussed in furtherdetail below, on return from the remote program link, the data in thecommon area storage 17 would reflect the updated information from theremote system 10 b as if it had been processed locally in the workingstorage 22B on the local system 10 a. In this way, the screens would beready for display to the user on the local system. The working storagearea 22B on the remote system 10 b may be defined and used in exactlythe same manner as the same program 16 a on the local system 10 a.

Still referring to FIG. 1, the memory 22A can include local memoryemployed during actual execution of program code, bulk storage, andcache memories which provide temporary storage of at least some programto reduce the number of times code must be retrieved from bulk storageduring execution. The computer infrastructure 12 further includes aprocessor 20, an input/output (I/O) interface 24, a bus 26, Storage “S”,ROM, RAM and an external I/O device/resource 28.

The external I/O device/resource 28 may be a keyboard, display, pointingdevice, or any device that enables the computer infrastructure 12 tocommunicate with one or more other computing devices using any type ofcommunications link 30. The communications link 30 can be, for example,wired and/or wireless links; one or more types of networks (e.g., theInternet, a wide area network, a local area network, a virtual privatenetwork, etc.); and/or any known transmission techniques and protocolssuch as, for example, TCP/IP.

The processor 20 executes the computer program code and logic of thesystem and method of the invention, which is stored in the memory 22A.While executing the computer program code, etc., the processor 20 canread and/or write data to/from the memory 22A, storage system 22B,and/or I/O interface 24. The bus 26 provides a communications linkbetween each of the components in the computing device 14.

As an alternative, the invention is configured for any computerapplication running on any operating platform that comprises a programexecuting on a local system that uses some representation of workingstorage containing variable data. In this embodiment, the computerapplication is configured to to send such data to a remote system,whereby the same program or a different program could use the data forit's own working storage, and return the updated storage to theoriginating program. The originating program working storage would bealtered to values updated by the remote program. This would includecommunication such as, for example, ( ISC), (TCPIP), and (MQSeries);although (DPL) would be the easiest to implement.

Architecture of Embodiments of the Invention

FIG. 2 shows an architecture in accordance with an aspect of theinvention. More specifically, the architecture includes a local system10 a and a remote system 10 b. Both the local system 10 a and the remotesystem 10 b include, for example, the same program “A”, 16 a, 16 b, aswell as a storage area 22B and CICS storage area 23. The architecturealso includes common area storage 17, which is a common storage for boththe local system 10 a and the remote system 10 b. As described herein,the program 16 b on the remote system 10 b will use information in thecommon area storage 17 as its working storage to collect and process therequested information and return it to the calling program on the localsystem 10 a. On return from the remote program link, the data in thecommon area storage 17 reflects the updated information from the remotesystem 10 b as if it had been processed locally in the working storage22B on the local system 10 a.

An EXECute CICS LINK is provided between the local system 10 a and theremote system 10 b. The EXECute CICS LINK is a standard function of theCICS command level interface. In embodiments, six fields are used withthe EXECute CICS LINK. In one non-limiting illustrative example, the sixfields include:

-   -   (i) PROGRAM name: The PROGRAM name identifies the name of the        program to execute on the remote system.    -   (ii) Remote System SYSID: The Remote System SYSID is used by        CICS to direct the request to a remotely attached CICS region,        e.g., region B. This SYSID should be predefined and connected.    -   (iii) COMMAREA: The COMMAREA defines the data that is passed to        the program on the remote system 10 b as a serialized structure,        which can be identified by a high level name.    -   (iv) LENGTH: The LENGTH is used to define the data length of the        common area 17.    -   (v) SYNCONRETURN parameter: The SYNCONRETURN parameter notifies        the remote system 10 b to commit any changes to protected        resources on completion on the program execution.    -   (vi) NOHANDLE parameter: The NOHANDLE parameter instructs CICS        to give control back to the application program (on the local        system) regardless of error conditions from the link command.        This allows the program to be aware of and handle a failure of        the link command.

In embodiments, the program 16 a (or 16 b) may display the current SYSIDvalue, optionally display a list of possible remote systems, andrecognize a request to change the SYSID value to a remote system (orback to the local system). Alternatively the program 16 a (or 16 b) canwork from a hardcoded list of remote systems. Thus, in use, the onlyrequirement for a user is to select the desired remote target system,which could be presented from a list or other similar method suitablefor the application.

The program 16 a (or 16 b) also uses a procedure to perform the remotedistributed program link with the common area and checks for errorconditions such as an invalid or unavailable remote system. The program16 a (or 16 b) is also configured to log the invalid or unavailableremote system condition or report back to the user such condition.

In embodiments, it is preferable that no variable length fields bedefined because the data structure requires a fixed length for the CICSlink common area 17. Also, any fields which are not relevant to thedistributed program link, such as local loop counters, pointers to localdata areas, local time, or user 3270 terminal related information may beexcluded from the data structure.

Additionally, following the CICS link all fields are updated as if theywere updated locally. In this manner, the CICS link is virtuallytransparent to the program residing on the local system 10 a (and hencethe user). Also, all information is shared between the programs “A” 16 aand 16 b on both ends of the channel, so current screen status, scrollinformation, function keys pressed by the user, and any other fieldsrequired to be session persistent are maintained in the working storage22B. In illustrative and non-limiting examples:

-   -   If repetitive functions are performed such as scrolling, the        current and next positions are always known and updated; and/or    -   If help screens or nested panels are displayed, the information        required to back out of the screens is maintained for both the        local program execution (e.g., on local system 10 a) and remote        program execution (e.g., on remote system 10 b), as if all        program functions were performed locally.

In implementation, writing a new program or converting an existingprogram includes defining all working or dynamic storage variables usedby the program 16 a (or 16 b) into a data structure with a high levelname of the structure. For an existing program, all of the variablesshould be collected and defined in this structure.

Flow Diagram Implementing Steps of the Invention

FIG. 3 represents a flow diagram implementing steps of the invention.The steps of FIG. 3 may be implemented in the environment of FIG. 1 orarchitecture of FIG. 2. The steps of the invention may equally representa high-level block diagram of the invention.

The invention can take the form of an entirely hardware embodiment, anentirely software embodiment or an embodiment containing both hardwareand software elements. The software elements may be firmware, residentsoftware, microcode, etc. Furthermore, the invention can take the formof a computer program product accessible from a computer-usable orcomputer-readable medium providing program code for use by or inconnection with a computer or any instruction execution system. For thepurposes of this description, a computer-usable or computer readablemedium can be any apparatus that can contain, store, communicate,propagate, or transport the program for use by or in connection with theinstruction execution system, apparatus, or device. The medium can be anelectronic, magnetic, optical, electromagnetic, infrared, orsemiconductor system (or apparatus or device) or a propagation medium.Examples of a computer-readable medium include a semiconductor or solidstate memory, magnetic tape, a removable computer diskette, a randomaccess memory (RAM), a read-only memory (ROM), a rigid magnetic disk andan optical disk. Current examples of optical disks include compactdisk—read only memory (CD-ROM), compact disk—read/write (CD-R/W) andDVD.

In embodiments, the invention provides a business method that performsthe steps of the invention on a subscription, advertising, and/or feebasis. That is, a service provider, such as a Solution Integrator, couldoffer to perform the processes described herein. In this case, theservice provider can create, maintain, deploy, support, etc., a computerinfrastructure that performs the process steps of the invention for oneor more customers. In return, the service provider can receive paymentfrom the customer(s) under a subscription and/or fee agreement and/orthe service provider can receive payment from the sale of advertisingcontent to one or more third parties.

Referring to FIG. 3, at step 300, the program starts on the localsystem. At step 305, the process declares a common data structure as anarea referenced by a pointer, containing various fields required for theexecution of the program. At step 310, in embodiments, the processdefines a constant length field to reference the length of the commonarea. At step 315, a pointer can be used to reference the defined datastructure, which can either be local storage on the local system or thecommon area provided in the CICS link on the remote system. At step 320,the process defines an area in local working or dynamic storage for theprogram when executing on the local system. In embodiments, at step 325,all of the initial values of the program executing on the local systemare stored in this area, as well as the ongoing values as the programprogresses through its functions.

At step 330, if there is a need to access a remote system, then theprocess provides an area having the initial values and any ongoingvalues to CICS in the remote program link, which is passed to the remotesystem as a common area. At step 335, using the information provided toCICS, in the remote program link, the program on the remote systemperforms its requested tasks and, at step 340, returns its informationto the local system via, for example, the common area. That is, theprogram on the remote system uses the information in the common areastorage as its working storage to collect and process the requestedinformation and return it to the calling program on the local system.

Examples of Operation

The program logic can be shown in the following non-limiting examples,written in PL/1 language but easily adapted to other languages. A commondata structure is declared as an area, referenced by a pointer,containing various fields required for the execution of the program.These fields may be defined as follows:

declare Pgm_Commarea based(Workarea_Ptr), Current_Screen char(8),Help_Flag char(1), Routed_Flag char1), Message_Text char(80), Screen_cmdchar(3), Current_Line fixed binary(31), Last_Line fixed binary(31),Return_Code fixed binary(31), Total_Records fixed binary(31);

A constant length field can be defined to reference the length of theCommarea (common area). By way of non-limiting example,

declare Commarea_Length fixed binary(15) initial(cstg(Pgm_Commarea)); /*set commarea length */

A pointer can be used to reference the defined data structure, which caneither be local storage on the local (originating) system 10 a or thecommon area provided in the CICS link (EXECute CICS LINK) on the remotesystem 10 b. By way of a non-limiting illustrative example:

declare Workarea_Ptr pointer; /* define a pointer to reference theworking storage */

An area may be defined in local working or dynamic storage for theprogram 16 a when executing on the local system 10 a. In embodiments,all of the initial values are stored in this area, as well as theongoing values as the program 16 a progresses through its functions. Ifthere is a need to access a remote system 10 b, then this area isprovided to CICS in the remote program link to be passed to the remotesystem 10 b as a common area, where it is updated and returned. By wayof a non-limiting illustrative example:

declare Pgm_Workarea char(cstg(Pgm_Commarea)); /* reserve a space forthe structure in working storage */

When the program 16 a first executes, a simple check may be made todetermine how the program 16 a was started. For example, if the program16 a was started with a commarea (e.g., by a check of the commarealength provided by CICS) via the Distributed Program Link, then thepointer to the working area is assigned from the CICS-provided commareaaddress. If the commarea length is zero, the program 16 a is determinedto be started locally by, for example, a 3270 terminal user or anotherbackground program. In the latter example, the pointer is assigned theaddress of the local dynamic storage area. By way of a non-limitingillustrative example:

if EIBCALEN = Commarea_Length then /* a commarea exists, program waslinked to */ Workarea_Ptr = DFHEICAP; /* reference working storage fromCICS commarea address */ else /* normal start on local system by user */Workarea_Ptr = addr(Pgm_Workarea); /* reference working storage indynamic storage area */

If the program 16 a was started on the local system 10 a, then thefields of the data structure (Pgm_Commarea data structure) are completedusing information on the local system 10 a and presented to the user. Ifa commarea exists, the program 16 b running on the remote system 10 bcan determine what information is being requested by the originatinglocal program and complete the data structure to be returned to theoriginator.

In embodiments, the program determines when a remote system 10 b needsto be accessed. When the transaction is 3270 user driven, for example,the program 16 b can request access from a field on the user's screen.In a background transaction environment, in another embodiment, accesscan be requested from a list of remote systems. By way of a non-limitingillustrative example, the code executing the distributed program linkcan include:

EXEC CICS LINK PROGRAM(‘PROGRAMA’) SYSID(ssss) COMMAREA(PGM_WORKAREA)LENGTH(COMMAREA_LENGTH) SYNCONRETURN NOHANDLE; if EIBRESP > 0 then /* anerror occurred on the link command */ do; /* perform error conditionhandling..... */ end;

The SYSID parameter contains the CICS target destination and thecommarea contains the program data. If the SYSID contains the localsystem definition, a local link is performed as if the SYSID was notdefined. Values in the commarea would indicate the operations that needto be performed by the program on the remote system 10 b. On return fromremote processing, the commarea will be updated with any changes fromthe program executing on the remote system. A 3270 screen would displaythe values on the remote system. The SyncOnReturn parameter notifies theremote system to take a syncpoint on completion of the executingprogram, to commit any protected resource changes. The NOHANDLEparameter notifies CICS to return control to the originating programeven if an error occurs in the LINK command, with the appropriate errorcode in the EIBRESP field.

In further implementations, the design of the system and method of theinvention also includes the capability of the program executing on theremote system to forward the request to another CICS region forprocessing. This is a form of intermediary routing. The commareareturned to the originating program would actually be updated by thesecondary remote system.

Exemplary Graphical Display

FIG. 4 shows an exemplary screen image of an application using thesystem and method of the invention. This screen can be representative ofinformation retrieved from a remote system, now displaying on a local,originating system.

By way of example, the field in the upper left corner, SYSID, is used toselect a remote system to display SDI (Simulation Database Interface)transaction information. The SYSID term is synonymous with the name of acomputer system. As assistance to the user, a list of possible values isdisplayed in the lower portion of the screen. In this example, the useris connected to the BX25 system. If any of the other available SYSIDvalues is typed into the SYSID field, any of the display optionsselected will cause the remote program call to retrieve the selectedinformation, and the resulting displayed screen will display informationacquired from the remote system. This will occur as if the user hadlogged off the connected system and logged into the remote system.Further, this operation can be repeated with all of the other systems inthe list to quickly collect a view of the entire network in a very shortperiod of time.

While the invention has been described in terms of embodiments, thoseskilled in the art will recognize that the invention can be practicedwith modifications and in the spirit and scope of the appended claims.

1. A method, comprising: sending programming functions of a local systemwith a request for information to a remote system; processing theprogramming functions of the local system with the request forinformation on the remote system to obtain updated information from theremote system; and sending the updated information to the local systemfor display.
 2. The method of claim 1, wherein the updated informationis retrieved from a common area storage accessible to both the localsystem and the remote system.
 3. The method of claim 2, wherein theupdated information is reflected as having been processed locally inworking storage on the local system.
 4. The method of claim 1, furthercomprising transferring the programming functions from the local systemto the remote system by providing defined dynamic storage to a sameprogram of the local system and the remote system.
 5. The method ofclaim 4, wherein virtually an entire working storage of the program ofthe local system is passed to and returned from the program of theremote system by use of the defined dynamic storage.
 6. The method ofclaim 1, further comprising allowing access to a storage area on theremote system using a program of the local system.
 7. The method ofclaim 6, further comprising organizing the program's working or dynamicstorage into a defined data structure; recognizing, validating andprocessing input for a remote system request; and performing aDistributed Program Link (DPL) call to a same program of the remotesystem, and passing a working storage data structure in a CustomerInformation Control System (CICS) Link Commarea which is a common areabetween the remote system and the local system.
 8. The method of claim1, wherein the steps of claim 1 are provided by a service provider. 9.The method of claim 1, wherein a service provider at least one ofcreates, maintains, deploys and supports a computer infrastructure thatperforms the steps of claim
 1. 10. The method of claim 1, wherein thesteps of claim 1 are provided on a subscription, advertising, and/or feebasis.
 11. A system for obtaining information from a remote system,comprising a computer infrastructure having one type of program for alocal system and the remote system, the program being operable to sendprogramming functions of the local system with a request for informationto the remote system, processing the programming functions of the localsystem and the request for information on the remote system and sendingthe updated information to the local system for display, via a definedcommon area storage.
 12. The system of claim 11, wherein the updatedinformation is retrieved from a common area storage accessible to boththe local system and the remote system.
 13. The system of claim 11,further comprising transferring the programming functions from the localsystem to the remote system by defined dynamic storage to the program ofthe local system and the remote system.
 14. The system of claim 13,wherein virtually an entire working storage of the program of the localsystem is passed to and returned from the program of the remote systemby use of the defined dynamic storage.
 15. The system of claim 11,further comprising a storage area on the remote system which isaccessible by the local system using the program of the local system.16. The system of claim 1 1, wherein a service provider at least one ofcreates, maintains, deploys and supports the program.
 17. The system ofclaim 11, wherein the program is configured to recognize, validate andprocess input for a remote system request.
 18. The system of claim 11,wherein the computer infrastructure is configured to perform aDistributed Program Link (DPL) call to the program of the remote systemand pass working storage data structure in a CICS Link Commarea.
 19. Thesystem of claim 11, further comprising a display for displaying theupdated information on the local system.
 20. A computer program productcomprising a computer usable medium having readable program codeembodied in the medium, the computer program product includes at leastone component to: send programming functions of a local system with arequest for information to a remote system; process the programmingfunctions of the local system with the request for information on theremote system to obtain updated information from the remote system; andsend the updated information to the local system for display.